I am curious how you landed on 15 rather than 10 or 20?

The existing value was 5, and I figured that (if I want all connection attempts to succeed immediately) I'm adding 10 new possible threads that might need a DB connection (5 single-threaded workers for the MeF jobs, 1 5-threaded worker for the callbacks).

I'm not actually sure of myself here (maybe the webhook callback worker actually only needs one db connection, since the job doesn't use the db and therefore the only need is for the worker to claim & execute jobs?) but that was my reasoning, faulty or not.

Are you running the queue embedded in the puma server or are you running the jobs queue stand alone? If running stand alone, I don't think you should need to change this.

I'm also unsure though about how many threads are reasonable for postgres. I've never really deviated from the default.

re puma server: i would imagine stand alone since there would be additional configuration for puma

queue is puma plugin in development, standalone elsewhere - see

The actual error I get when running bin/rails s in development is:

Solid Queue is configured to use 7 threads but the database connection pool is 5. Increase it in `config/database.yml`

I assume the 7-thread requirement is coming from the 5-threaded webhook callback worker, per this note in the solid_queue docs:

It is recommended to set this value less than or equal to the queue database's connection pool size minus 2, as each worker thread uses one connection, and two additional connections are reserved for polling and heartbeat.

I'm going to resolve this by reducing the number of threads that the webhook callback worker uses to 3, rather than increasing the db connection pool, since I'm also uncertain about the impact of the latter option and the former should be relatively low-impact (since our webhook callback jobs shouldn't take long to complete, since I'm also adding a 5-second timeout to all webhook callback requests, down from the default of 60(!))